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Prufungsantrag gem. § 44 PatG ist gestellt 

@ Verfahren zur ko n texts pezifisc hen Remote-Authentifizlerung des Datenzugriffs 

(§) Die bislang bekannt kryptografischen Verfahren erlau- 
ben mittels nur einer Chipkarte, die entweder vom Arzt 
oder vom Patienten gefuhrt wird, entweder den Zugriff 
auf den gesamten Datenbestand des einzelnen Patienten 
oder auf Daten betiebig anderer Patienten. 
Das neue Verfahren soli dem Arzt nur dann den Zugriff auf 
verschlusselte personenbezogene gesundheitsrelevante 
und auch nur aus der Fachgruppe des fur den Arzt rele- 
vanten Daten ermoglichen, wenn der Patient tatsachlich 
in der Praxis anwensend ist und durch Freigabe seiner 
Chipkarte sein Einverstandnis erklart. 
Sowohl Arzt als auch Patient verfugen uber eine krypto- 
grafische Chipkarte, die aufgrund der verfahrenseigenen 
Verschlusselung der Obertragungswege bei Einfuhren 
beider Karten in ein Lesegerat an einem Rechner in der 
■ Arztpraxis die Authentifizierung eines Datenzugriffs 
durch me hrere Person en gewahrleistet. 
Das Verfahren eignet sich fur den medizinischen und je- 
deri Bereich, in dem datenschutzrelevante Daten zum Ein- 
satz kommen. 
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Beschreibung 

2.1 Technisches Gebiet 

5 [0001] Zugriffskontrolle auf elektroniseh gespeicherte, vertrauliche und schutzbediiftige Daten in verteilter und hete- 
rogener Umgebung, insbesondere auch im Internet 

2.2 Stand der Techhik 

10 [0002] Die dargestellte Erfindung baut im wesentlichen auf der Technologie des Internets sowie kryptographischer 
Verfahren auf, also solcher, die digitale Verschlusseiung und Signatur verwenden. 

[0003] Soweit moglich, wird zum Stand der Technik auf die im Internet anerkannten RFC ("Request for Comments") 
Bezug genommen, die z. B. unter http:/ / www.rfc-editor.org abrufbar sind. Diese RFC erfiillen einerseits die Funktion 
anerkannter Standards, andererseits dienen sie auch zur fachlichen Diskussion, so daB neue Entwicklungen hier friihzei- 
15 tig ihren Niederschlag finden 

2.2.1 Internet-Protokolle 
2.2.1.1 TCP/IP 

20 

[0004] Das Riickgrat des Internets bildet eine standardisierte Gruppe von Netzwerk-Ubertragungsprotokollen, die hau- 
fig unter dem Kurzel "TCP/IP" zusammengefaBt werden aber im weiteren Sinne auch beinhalten: 

- Das "Internet-Protocol" (IP, [RFC 791]) weist jedem Rechner im Internet eine eindeutige Adresse aus 4 Bytes zu 
(typische Notation 123.234.56.78) Mehrere Rechner konnen zu Subnetzen zusammengefaBt werden. 
Der Datentransfer erfolgt in Paketen (typ. ca 1 kByte groB) Schnittstellenrechner ("Router") ubernehmen als Ver- 
mittlungsstellen die Verbindung zwischen Subnetzen. MuB ein Paket fiber mehrere Subnetze hinweg transportiert 
werden, wird es von Router zu Router weitergereicht. Im NormalfaLL ist davon auszugehen, daB weder Sender noch 
Empfanger die Kontrolle iiber alle Router und Subnetze der Ubertragungsstirecke besitzen. Deswegen gilt das Inter- 
net als inharent unsicher und anfalUg fur Abhoren und Verfalschen von Daten sowie falsche Identitatsbehauptungen 
("IP-Spoofing") 

Eine neue Version des Internet-Protokolls (IP-V6, siehe [RFC 1883]) ist in Vorbereitung, hat sich aber noch nicht in 
der Praxis etabliert. 

- Das "Transmission Control Protocol" (TCP, [RFC 793]) setzt auf IP auf und verdeckt die Paketubertragung vor 
den Anwenderprogrammen. Eine Anwendung fordert von TCP eine Verbindung zu einem bestimmten Rechner 
(identifiziert iiber die IP- Adresse) an. TCP stellt der Applikationen "Sockets" zur Verfugung, ein Schnittstellenpaar, 
iiber die sequentiell Daten gelesen und geschrieben werden konnen. Diese Sockets korrespondieren mit denen an 
der Gegenstelle, so daB die Anwendungen auf beiden Rechnern iiber dieses Socket-Paar kommunizieren konnen, 
ohne sich um die darunterliegende Netzwerkstruktur zu kummern. 

Um an einem Rechner verschiedene Programme (oder mehrere Instanzen des selben Programmes) unabhangig von- 
einander Verbindungen aufbauen zu lassen, beinhaltet TCP eine "Port- Adresse", die einen bestimmten Socket von 
ggf. mehreren auf einem Rechner identifizieren kann. 

- Das "User Datagramm Protocol" (UDP, [RFC 768]) ist eine etwas einfachere Alternative zu TCP und setzt eben- 
falls auf EP auf. UDP kennt keine Verbindungen wie TCP, sondern sendet beliebig lange Datensequenzen ("Datag- 
ramme") an die Gegenstelle, ohne auf eine Bestatigung zu warten. UDP verdeckt damit vor allem die ^Vermittlungs- 
schicht und die Paketstruktur. 

Auch UDP kennt, wie TCP, mehrere Ports auf einem Rechner. 

- Das Domain-Name-System (DNS, siehe [RFC 1034)/[RFC 1035]) ermoglicht die Zuordnung von Netzwerk- 
adressen zu leicht einpragsamen Namen (typische Notation: host.organisation.land) und die Uberlagerung einer or- 
ganisatorisch ausgerichteten Gliederung des Netzes iiber die technische Struktur der IP-Adressen mit den Sub-Net- 
zen. 

Das DNS -System ist als verteilte Datenbank mit vielen Zwischenspeichern ausgelegt. Damit wird es (bei korrekter 
Konfiguration) sehr stabil, jedoch anfallig fiir MiBbrauch durch bewuBte Fehlkonfiguration ("DNS -Spoofing") in 
begrenzten Netzsegmenten. 
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2.2.1.2 Universal Ressource Locators 

[0005] Universal Ressource Locators (URL [RFC 1738]) ordnen jeder Netzwerkressource (z, B, Rechner, Mail-Konto, 
60 Textdatei, Bilddatei, Tondatei) einen String zu, iiber den die Ressource im Internet erreicht werden kann. URL enthalten 
typischerweise das verwendete Applikationsprotokoll, den anzusprechenden Server und ggf. weitere Informationen zur 
Spezifikation der Ressource relativ zum Server. 

[0006] Das Konzept der URL wurde im aktuell giiltigen Standard zum "Universal Ressource Identifier" (URI, [RFC 
2396]) erweitert, das iiber die Netzerreichbarkeit hinaus Ressourcen eindeutig identifiziert. 
65 [0007] Eine URL kann auch ein Programm oder Program- Schnitts telle identifizieren. In diesem Fall kann sie eine 
."query" enthalten, also eine Einheit von Daten, die vom identifizierten Programm interpretiert wird. 
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2.2.1.3 http 

[0008] HTTP ("Hypertext Transport Protocol") setzt als AnwendungsprotokoU auf TCP auf. Aktuell im Einsatz sind 
die Versio nen h ttp 1.0 ([RFC 1945]) und http 1.1 ([RFC 2616]). 

[0009] HTTP verbindet einen Client (typischerweise einen WWW-Browser) mit einem Server (einen Web-Server). 
Der Client sendet eine Anfrage an den Server, mit der er urn die Obermittlung von Daten bittet. Sowohl der angespro- 
chene Server als auch die Identifikation der Daten auf dem Server erfolgt uber eine URL. ' 
[0010] http erfolgt in isolierten "Request-Response"-Zyklen, zwischen denen keine Verbindung zwischen Client und 
Server aufrecht erhalten wird. Folgende Request- Arten sind gebrauchlich: 



2.2.1.4 HTML, XML und Hyperlinks 



10 



- GET: Der Client bittet urn die Obermittlung einer Datei. 

Falls die adressierte Ressource keine Datei, sondern ein Programm ist, kann erganzend noch eine "query", also eine 
Datensequenz, mitgereicht werden. In diesem Fall erstellt das aufgerufene Proramm eine Antwortdatei, die im Re- 
sponse zuriickgereicht wird. 

- POSTi Der Client ubermittelt an den Server eine Liste von Variablen mit Werten. POST-Requests sprechen fast 15 
immer Programme auf der Gegenseite an. POST-Requests resultieren typischerweise aus ausgefullten HTML-For- 
mularen. 

[0011] Weitere Request- Arten (PUT, DELETE. . .) sind dagegen wenig gebrauchlich. 

[0012] Das HTTP-Protokoll ermoglicht eine Authentifizierung des Benutzers (d. h. des Browsers gegenuber dem Ser- - 20 
ver) mit Benutzemamen und Password 

[0013] Um http mit Status-Informationen zu erweitem, d. h. dafur zu sorgen, da£ ein Server sich an Details eines vor- 
hergehenden Requests des gleichen Clients "erinnem" kann, gibt es zwei gangige Mechanismen. Damit kann das an sich 
statuslose Protokoll das Konzept einer "Session", also einer Reihe von Request-Response-Zyklen mit inhaltlichem Zu- 
sammenhang, implementieren: 25 

- Alle Seiten mit Hyperlinks innerhalb einer Session werden dynamisch generiert. 

Die Session- Variablen werden dabei an die Query aller internen Hyperlink-URLs angehangt (fur GET-Requests) 
bzw. als POST- Variablen, z. B. in versteckten Formularfeldern, hinterlegt. Beim Aktivieren der Links werden diese 
Daten dann vom Browser wieder mit an den Server zuriickgesandt. 30 

- Eine Erweiterung des Standards ([RFC 2965]- "Cookies") ermoglicht es dem Server, im Response ein Variablen- 
Wert-Paar an den Browser zu senden, das dieser lokal speichert und dann bei jedem Request an den selben Server 
mit ubermittelt. 



35 



[0014] Die "Hypertext Markup Language" HTML wurde zunachst bis zur Version HTML 2.0 ([RFC 1866]) im Rah- 
men der Intemetstandards definiert. Tnzwischen (mit [RFC 2854]) wurde die Definition an das w3-Konsortium ubertra- 
gen und weiterentwickelt ([HTML401], [XHTML1], [XML]). 40 
[0015] HTML ermoglicht die formatierte Darstellung von Text (z. B. SchriftgroBe, Absatzformate, Tabellen usw.) so- 
wie das Einbinden beliebiger anderer Dateiformate (z. B. Bilder, Sound, Videos). 

[0016] Dariiberhinaus besitzt HTML "Hyperlinks", also Sprungverweise zu anderen Seiten, die im HTML-Quelltext 
mit ihrer URL definiert sind. 

[0017] HTML und HTTP zusammen bilden das WWW (World Wide Web). Durch die in die Seiten eingebettet en Hy- 45 
perlinks erscheint dem Benutzer der Eindruck, er wurde auf einer Gruppe von Seiten "sich befinden", obwohl das HTTP- 
Protbkoll keinen Verbindungsstatus kennt. Da die URL jeden beliebigen WWW-Server referenzieren konnen, erlaubt die 
geschickte Kombination von HTML^Seiten das Erstellen von " Applikationen", die sich uber mehrere Server, moglicher- 
weise weltweit verteilt, erstrecken. Durch die Einbindung von Programmen, die auch (iiber HTTP-POST oder eine query 
in HTTP-GET) Benutzereingaben annehmen, laBt sich die Funktionalitat dieser "Web- Applikationen" beliebig erweitem 50 
und viele gangige Benutzeroberflachen einer Software funktional nachbilden. 

2.2.1.5 ssl und tls. 

[0018] Die Datenubertragung in TCP/IP und damit auch in HTTP erfolgt grundsatzlich unverschlusselt und mit be- 55 
grenzter Fehlerkontrolle. Ein boswilliger Angreifer, der Zugang zu geeigneten Routern hat, kann den Datenverkehr ab- 
horen und verfalschen. 

[0019] Um dies zu verhindern, hat die Firma Netscape eine zusatzliche Protokollebene standardisiert, die als ssl (siehe 
[SSL2]) bekannt ist. ssl setzt auf TCP auf und stellt der Applikation wiederum Sockets zur Verfiigung (ist also fur die 
Applikation wahrend der tFbertragung wieder transparent), ermoglicht aber die Absicherung der Ubertragung mit ver- 60 
schiedenen kryptographischen Methoden (symmetrische Schliissel, asymetrische mit ein- oder beidseitiger Authentifi- 
zierung) wie sie weiter unten beschrieben sind. 

[0020] SSL wurde in einer Erweiterung als TLS ([RFC 2246]) in die Internet-Standards aufgenommen. 

2.2.1.6 https 65 

[0021] https, auch S-HTTP genannt, ist in [RFC 2660] spezifiziert und stellt die Implementierung des http-Protokolls 
iiber ssl- bzw. tls-Verbindungen dar. Algorithmen und Schnittstellen zur kryptographischen Infrastruktur sind in den gan- 
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gigen Web-Servern- und -Browsern implementiert. 

2.2.1.7 FirewaU 

5 [0022] Da das Internet als unschutzbarer, offentlicher Raum gilt, mussen die Zugange zu Netzen, die vertrauenswiir- 
dige Daten enthalten, entsprechend vor unberechtigtem Eindringen geschutzt werden - verjgleichbar der Pforte an einem 
Werkseingang. Die entsprechenden Vorrichtungen bezeichnet man als "Firewall". Einen Uberblick uber Techniken und 
Begriffe vermittelt [RFC 2647]. 

10 2.2.1.7.1 Firewall-Prinzipien 

[0023] Firewalls verwenden zwei Grundprinzipien: 

- Paketfilter: Es handelt sich hier um spezielle Router (vgl. Abschnitt TCP/IP), die zwischen dem externen und 
15 dem intemen Subnetz stehen und nur nach bestimmten Regeln, ausgehend von Quell- und Zieladressen der Pakete, 

eine Verbindung herstellen, abweisen oder umleiten. 

Paketfilter konnen meist auch IP-Adressen umwandeln ("Network address translation" NAT oder "Masquerading"). 

- Application-Level-Filter: Diese Filter treten gegenuber den Kommunikationspartnern als Gegenstelle aus und 
werten den Inhalt der ubertragenen Daten aus (z. B. Datentypen, Inhalt, Viren usw.). Je nach Ergebnis der Auswer- 

20 tung wird der Inhalt dann transparent ubertragen, gesperrt, verandert oder auch nur der Transfervorgang protokol- 

liert. 

Neben Sicherheitsuberpriifungen konnen diese Filter auch Daten zwischenspeichern und werden dann als "Proxy"- 
Server bezeichnet, wobei der Begriff auch synonym fur Application level filter verwendet wird. 
Application level filter mussen das jeweilige Protokoll (z. B. Mail, ftp, http. . ,) verstehen, um den Inhalt analysieren 
25 zu konnen. 



2.2. 1 .7.2' Firewall- Architekturen 

30 [0024] Die Firewalls-Komponeriten werden zu "Firewall- Architekturen" kombiniert. Gangige Grundkonfigurationen 
sind: 

Einfacher Paketfilter: 

(Internet) <Paketfilter> (internes Netz) 

35 

Routing findet nur nach festgelegten Regeln statt. 
Es findet keine Inhaltsiiberprufung statt. 
Einfacher Proxy: 

40 (Internet) <Proxy> (internes Netz) 

Es findet kein direktes Routing zwischen intemem Netz und Internet statt. 
Nur Protokolle, die im Proxy implementiert sind, konnen ubertragen werden. 
Dreigliedrige Firewall: 

45 

(Internet) <Paketf ilter>— (internes Netz) 

I 

( DMZ) 

+ — <Proxy> 

+ — <Web-, Mail-, . -Server> 

50 

Zweistufige FirewaU: 

(Internet) <Paketf . 1> — +--<Paket f . 2>-- (internes Netz) 

I 

„ (DMZ) 

+--<Proxy> 

+--<Web-, Mail-, ... -Server> 

[0025] Bei der dreigliedrigen und der zweistufigen Firewall wird zwischen Internet und internem Netz eine "Entmili- 
tarisierte Zone" (engl. demilitarized Zone = DMZ) als eigenes Subnetz - gleichsam als Sicherheitsschleuse - geschaffen. 
60 [0026] Innerhalb der DMZ gelten niedrigere Sicherheitsanforderungen als im internen Netz, viele unberechtigte Zu- 
griffe aus dem Internet werden jedoch bereits von der ersten Paketfilterstufe abgefangen. 

[0027] In der DMZ befinden sich typischerweise die Proxy-Server zur S teuerung des Zugriffs zum internen Netz sowie 
ggf. die offentlichen Server der Organisation. 

65 2.2.2 Kryptographie 

[0028] Die digitale Kryptographie lost unter Anwendung mathematischer (meist zahlentheoretischer) Verfahren ver- 
schiedene Sicherheitsanforderungen der digitalen Kommunikation wahrend der Speicherung und/oder Ubertragung, ins- 
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besondere 

- Schutz vor unberechtigtem Zugriff von Daten durcb Dritte 

- Schutz vor unberechtigter Anderung von Daten 

- Identification und Authentifizierung von Sender und Empfanger 5 

- uberprufbare Verbindlichkeit und Unwiderrufiichkeit von elektronisch abgegebenen Erklarungen 

[0029] In der vorliegenden Erfindung werden verschiedene etablierte, im Folgenden eriauterte, Verfahren kombiniert 
[0030] Auf die tatsachlich erreichbare Sicherheit der Verfahren sowie deren EinfluBparameter (Schliissellange, organ- 
siatorische MaBnahmen, physikalische Sicherheit usw.) wirci hier nur insofem eingegangen, als sie zum Verstandnis der 10 
Erfindung relevant sind. Alle Erlauterungen beziehen sich auf die Annahme nicht korrumpierter Systeme. 

2.2.2.1 symmetrische Verschlusselung 

[0031] Die einfachste Form der verschliisselten Dateniibertragung verwendet zur Ver- und Entschlusselung die gleiche 15 
Binarsequenz als Schlussel'. Gangige Verfahren sind in [DES] und in [3DES] beschrieben. Eine verschliisselte Nachricht 
kann nur von jemandem, der uber den gemeinsamen Schliissel verfugt, gelesen werden. 

[0032] Wollen mehrere Parteien vertraulich miteinander kommunizieren, so besteht entweder (bei Verwendung eines 
gemeinsamen Schlussels) nur ein gemeinsamer vertraulicher Kommunikationsraum oder es muB fiir alle Kommunikati- 
onspaare ein eigener Schliissel vereinbart werden. 20 

2.2.2.2 Asymmetrische Verschlusselung 

[0033] Die symmetrische Verschlusselung erfordert eine vorab vorhandene vertrauliche Verbindung, um den Schliissel 
auszutauschen. Dies kann in der typischen elektronischen Kommunikation haufig nicht gewahrleistet werden. Diese Ein- 25 
schrankung umgehen asymmetrische Verfahren. Dabei verfugt jede Partei iiber einen Teil des Gesamtschlussels, beide 
Teile mussen (nach spezifischen Kriterien des Algorithmus) zusammenpassen ("Schlussel-ScWoB-Prinzip"). 
[0034] Eine Nachricht, die mit einem Schlusselteil verschliisselt wird, kann nur mit dem jeweils passenden Teil des 
Schlusselpaares entschlusselt werden. Die Reihenfolge, in der die Schlussel angewendet werden, ist dabei (zumindest bei 
RSA) gleichgiiltig, ebenso konnen mehrere Schlusselpaare nacheinander angewendet werden. 30 

2.2.2.2.1 Algorithmen 

[0035] Bekannte Algorithmen fur asymmetrische Verschlusselung sind Diffie-Hellman ([RFC 2631] [US-Pat No. 
4,200,770]) und RSA ([RSA] [RFC 23 1 3] (als PKCS #1); [US-Pat No. 4,405,829]), DS A sowie Algorithmen auf der Ba- 35 
sis EUiptischer Kurven ([PKCS13]). 

[0036] Soweit nicht anders angegeben, beziehen sich die folgenden Ausfuhrung auf RSA, sind aber weitgehend auf an- 
dere Algorithmen ubertragbar. 

2.2.2.2.2 Public-Private-Key- Verfahren 40 

J 

[0037] Bei diesem Verfahren (oft auch mit PKI - Public Key Infrastructure - referenziert) behalt jeder Teilnehmer an 
einem Kommunikationssystem einen Schlussel des Paares, wahrend der andere an alle anderen Teilnehmer veroffentlicht 
wird. 

45 

2.2.2.2.2.1 Verschlusseln 

[0038] Zum Verschlusseln einer Nachricht gegen unberechtigtes Lesen verschliisselt der Sender mit dem ihm bekann- 
ten offentlichen Schlussel des Empfangers. Nur dieser verfugt uber den dazu passenden privaten Schlussel und kann die 
Nachricht entziffern. 50 

2.2.2.2.2,2 Sighatur (digitale Unterschrift) 

[0039] Der Sender verschliisselt seine Nachricht mit seinem eigenen privaten Schlussel. Jeder im System kann diese 
Nachricht lesen, da der dazugehdrige Schlussel im Paar per Definition offentlich ist. 55 
[0040] Das Lesen mit dem offentlichen Schlussel des Senders gelingt jedoch nur, wenn tatsachlich der private Schlus- 
sel des behaupteten Senders zum Verschlusseln verwendet wurde. Ein boswilliger Dritter, der sich miBbrauchlich als 
Sender ausgeben mochte, aber nicht iiber dessen privaten Schliissel verfugt, kann dies nicht erreichen. Damit ist die Au- 
thentizitat des Senders gesichert. 

[0041] Der Sender kann eine einmal abgegebene Nachricht nicht verleugnen, wenn sie entziffert werden konnte, da nur 60 
er in der Lage war, diese Nachricht zu erzeugen. 

2.2,2.2.2.3 Trust-Center 

[0042] Public- Key-Systeme erfordern, daB jeder Kommunikationsparther sich auf die Echtheit der von ihm verwende- 65 
ten offentlichen Schliissel verlassen kann. 

[0043] Im einfachen Fall kann das durch einen vorherigen Austausch mit dem Inhaber uber einen sicheren Kanal er- 
folgen. Der erforderliche Austauschaufwand steigt jedoch mit dem Quadrat der Teilnehmer und wird deswegen in gro- 
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Beren Systemen zu aufwendig. 

[0044] Fur diesen Fall kann eine " Vertrauenswiirdige Sidle" (haufige Synonyme: Zertifzierungss telle, Netznotar, Cer- 
tificate Authority, Trust-Center) zwischengeschaltet werden. Der einzelne Nutzer tauscht nur mit dieser SteUe die offent- 
lichen Schlussel iiber einen sicheren Kanal aus. Das Trust-Center "signiert" den offentlichen Schlussel der Benutzer und 
5 stellt so deren Integritat sicher. 

[0045] Die Verteilung der signierten offentlichen Schlussel ("Zertifikate") kann .durch den Benutzer selbst - z. B. mit 
einer Nachricht oder durch Veroffentlichung im Nutzerkreis - erfolgen. 

[0046] Trust-Center-Zertifikate konnen auch kaskadiert werden ("Certificate Chain"), d. h, die Integritatspriifung er- 
folgt indirekt uber ein Center, das dem betreffenden Nutzer gegeniiber nicht direkt, sondern iiber ein weiteres Trust Cen- 
10 ter authentifiziert wurde. Analog konnen zwei zunachst unabhangige Trust-Center sich gegenseitig zertifizieren (Cross 
Certificate) und so die Benutzerkreise vereinigen. 

[0047] Einzelheiten des ublichen (standardisierten) Verfahrens sind in [X.509] beschrieben. 

2.2.2.2.2.4 Verzeichnis-Dienste 

15 

[0048] Die Veroffentlichung der X 509-Schlussel kann in sogenannten "Verzeichnissen" nach [X.500] erfolgen, wie 
sie speziell fur das Internet in [RFC 2459] und [RFC 2510] beschrieben sind. 

[0049] Das gangige Protokoll hierfur ist LDAP [RFC 1777], insbesondere in der aktuellen Version LDAP v3 [RFC 
2251]. 

20 [0050] Diese Verzeichnisse sind als eigenstandige Serverdienste angelegt. Sie ermoglichen die Suche eines Kommuni- 
kationspartners nach verschiedenen Kriterien (unter anderem auch eines weltweit eindeutigen, hierarchischen Namens 
nach X.500-Konvention, auch als DN = "distinguished Name" bezeichnet). Die Hinterlegung von X^509-Zertifikaten in 
LDAP- Verzeichnissen ist Bestandteil der Spezifikation. 

25 2.2.2.2,2.5 Smart-Cards 

[0051] Empfindlichste AngrifFsstelle fur ein PKI ist der Zugriff Unbefugter auf einen privaten Schlussel. Da es sich da- 
bei nur um eine binare Sequenz handelt, kann dieser Schlussel unbemerkt kopiert und von einem Angreifer verwendet 
werden (PC-Wartung, Verwendung in einem fremden Rechner, bosartige Software auf einem PC. . .). 
30 [0052] Um dies zu verhindern, konnen die privaten Schlussel auf unabhangigen Geraten gespeichert werden, die die 
erforderlichen Verschlusselungsoperationen durchfuhren, ohne daB der private Schlussel das Gerat verlaBt, und die kon- 
struktiv uberhaupt nicht in der Lage sind, den privaten Schlussel auszugeben. Unter verschiedenen vorgeschlagenen 
Bauformen hat sich hierzu die "Smart-Card" im Kreditkartenformat etabliert (siehe [ISO 78 16]- 15). 
[0053] Das Datenblatt eines Beispielproduktes findet sich unter [SecurlD 3100]. 

35 

2.2^2.2.2.6 Biometrische Identifizierung 

[0054] Smart-Cards und ahnliche "Security Tokens" konnen entwendet oder vom Inhaber im guten Glauben leichtfer- 
tig iiberlassen werden. Biometrische Verfahren (z. B. Fingerabdruck, Iris-Muster) ermoglichen dagegen die eindeutige 
40 Identifizierung einer Person direkt anhand von Korpermerkmalen. 

[0055] AUerdings ist die Zuverlassigkeit biometrischer Verfahren von der Integritat der priifenden Systeme am Ort der 
zu identifizierenden Person abhangig (vgL [^ionietrics]). In der Remote- Authentifizierung kann ein Angreifer durch ein 
fingiertes System die Reaktion eines echten Systems vortauschen, ohne daB die zu identifizierende Person tatsachlich an- 
wesend ist. 

45 [0056] Es bietet sich jedoch an, die Verwendung privater Schlussel auf Smart-Cards (oder anderen Tokens) mit biome- 
trischer Zugriff skontrolle zu sichern, so daB vor jeder Verwendung des privaten Schlussels ein willentlicher Akt des In- 
habers vorausgehen muB (Vergleiche auch [ISO 78 16]- 11 bzw. zugehorige Normierungsentwurfe). 

2.2.2.3 Hybrid- Verfahren 

50 

[0057] Asymmetrische Verfahren erfordem aufgrund ihrer Komplexitat wesentlich hoheren Rechenaufwand als sym- 
metrische Verfahren. Dies wird durch die Verwendung von (meist sehr minimalistischen) Tokens wie Smart-Cards weiter 
verscharft, die im Gegensatz zu modernen Prozessoren in Anwendungsrechnern nur einen sehr begrenzten Datendurch- 
satz aufweisen. 

55 [0058] In vielen Einsatzgebieten werden deshalb verschiedene Verfahren kombiniert, um den Datendurchsatz zu opti- 
mieren. 

2.2.2.3.1 Session Keys 

60 [0059] Ein "Session Key" ist eine Zufallszahl, mit der unter Anwendung eines syrnmetrischen Verfahrens der GroBteil 
des Kommunikationsinhaltes verschliisselt wird, 

[0060] Das asymmetrische Verfahren (und ggf. das minimalistische Token) braucht dann nur mehr den Session Key 
verschliisseln. Dieser verschliisselte Session Key wird zusammen mit der (symmetrisch) verschliisselten Nachricht iiber- 
tragen. Der Empfanger entschliisselt zunachst den Session Key und mit diesem dann den Rest der Nachricht. 

65 

2.2.2.3.2 Hash-Funktionen 

[0061] Hash-Funktionen sind sogenannte Einweg-Funktionen, die aus einer langeren Datensegenz einen (im statisti- 
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schen Rahmen) vergleichsweise kurzen, aber eindeutigen Wert (vergleichbar einer Prufsumme) ermitteln, der oft auch 
als "Fingerprint" oder "Hash- Wert" bezeichnet wird. Umgekehrt ist es jedoch nicht moglich, aus der "Prufsumme" auf 
die paten selber zu schlieBen. 

[0062] Gangige Algorithmen sind bekannt unter den Namen MD2, MD4, MD5 (siehe hierzu [RFC 1321]) oder [SUA], 
Die Anwendung von Hash-Funktionen rindet sich etwa als HMAC unter [RFC 2104]. 5 

2.2.2.3.3 E-Mail und S-MIME 

[0063] Das Verschlusseln und Signieren von elektronischen Nachrichten als E-Mail ist weit verbreiteL Alle gangigen 
e-Mail-Progr amine verfugen uber die entsprechende Technologic Die Technologie und Inrrastruktur ist ausgereift und 10 
kann als "Musterlosung" fiir die Implementierung komlexer kryptographischer Verfahren gelten. 

[0064] Die Details des Standards "S-MIME" fur verschlusselte Ubertragung von e-Mails im Internet sind in [RFC 
1421], [RFC 1422], [RFC 1423] und [RFC 1424] festgelegt. 

2.2.2.4 Authentifizierungs-Token 15 

[0065] In alien verteilten Rechnersystemen (meist Client- Server-Systeme) ist eine Authentifizierung des Benutzers am 
Zielrechner erforderlich. Im einfachen Fall authentifiziert sich der Benutzer (typischerweise mit Benutzername und Pass- 
wort) an jedem Zielsystem einzeln. Bei groBeren Systemen fuhrt das zu einem erheblichen Adrninistrationsaufwand im 
System und zur Verwirrung der Benutzer mit vielen Passwortern. 20 
[0066] Authentifizierungs verfahren mit einem eigenstandigen Priifsystem sind seit langerem bekannt. Bei diesen Ver- 
fahren exisriert neben der datenanfordernden Stelle (z. B einem Arbeitsplatzrechner, also dem Client) und der datenhal- 
tenden Stelle (z. B. einem Fileserver) ein eigener Authentifizierungsrechner. Der Client meldet sich zunachst am Authen- 
tifizierungsrechner an, nur dieser muB in der Lage sein, die Identitatspufung fur jeden Nutzer vorzunehmen. Er erstellt 
dann ein "Token" oder "Ticket" nach kryptographi schen Methoden, das an den Client zuriickubermittelt wird. Mit die- 25 
sem Token kann der Client sich dann an verschiedenen Datenservem authentifizieren. 



2.2.2.4.1 Kerberos 

[0067] Als Prototyp der Token-basierten Authentifizierung gilt das am MIT entwickelte Kerberos, das in seiner aktu- 30 
ellen Version V5 als Internet- Standard ([RFC 1510]) etabliert ist. Eine Kerberos- Variante wird unter anderem auch im 
Microsoft-Betriebssystem WINDOWS 2000 eingesetzt und lost dort einen proprietaren Mechanismus, wie er in NT 4 
verwendt wurde, - ab . 

[0068] Kerberos verwendet symmetrische Schlussel fur jeden Benutzer, die in den Authentifizierungsrechnem abge- 
legt sind. 35 

2.3 Problemsteilung 



2.3.1 Konkrete Aufgabenstellung im medizinischen Umfeld 

40 

[0069] Ein Arzt behandelt einen Patienten und braucht dazu Daten (z. B. Befund, Rontgenbild. . .), die von einem Drit- 
ten (z. B. einem Krankenhaus, einem Labor oder einer anderen Arztpraxis) - "Datenhalter" genannt - gespeichert wer- 
den. 

[0070] Verschiedene Rechtsvorschriften, Berufstandsregeln, Vertrauenserwartungen der Patienten, Vertrauenskonstel- 
lationen usw. verpflichten den Datenhalter, nur berechtigten Personen einen ZugrifT auf definierte und von den jeweiligen 45 
Personen abhangigen Bereich der Daten zu gewahren. 

[0071] Erforderliche Informationen, die der Datenhalter braucht, um Zugriffsentscheidungen zu treffen, sind etwa: 

- Ist die anfordernde Person tatsachlich Arzt und wenn ja, in welchem Fachgebiet? 

- Ist der Patient, den die Daten betreffen, anwesend und hat er seine Zustimmung erteilt? 50 

- Ist sich der Patient uber die gespeicherten Daten im Einzelnen bewuBt (will er z. B, einem Arzt, der ihn im Auf- 
trag einer Versicherung untersucht, offenbaren, daB es umfangreiche Daten aus einer Herzklinik gibt)? 

- Gibt es eine besondere Vertrauensstellung zwischen der anfordemden Stelle und dem Datenhalter, z. B. aufgrund 
besonderer vertraglicher Regelungen? 

55 

[0072] Die Anwendung der gebotenen hochsicheren Obertragungs verfahren nach dem Stand der Technik uberfordert 
regelmaBig die beteiligten Parteien, so daB die Absicherung der Ubertragung an Dritte ("sicherheitsvermittelnde Stelle") 
auszulagern ist, die jedoch keine Berechtigung haben, die Daten selber zu lesen. 

[0073] Kosten- und Effizienzkriterien erfordern, daB auf Seiten des Datenhalters und der sicherherheitsvermittelnden 
Stelle die Abwicklung ohne direkte EinfluBnahme von Menschen erfolgt. 60 
[0074] Neben der reinen Authentifizierung der beteiligten Personen konnen noch weitere Informationen des Anforde- 
rungskontextes erforderlich werden, die ggf. iterativ abgefragt werden miissen. 

2.3.2 Verallgemeinerung der Problemsteilung 

65 

[0075] Die dargestellte Losung betrifft die Verschlusselung der tjbertragungswege und beinhaltet keine Einschrankung 
der Daten selber, deswegen kann der Einsatz auch auBerhalb des medizinischen Umfeldes erfolgen. 
[0076] Damit kann die Aufgabenstellung erweitert werden: 
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Es soil einem datenverarbeitenden System ermoglicht werden, bei einem angeforderten Datenzu griff Informationen iiber 
den Kontext des beabsichtigten Zugriffs, insbesondere mehrerer beteiligter Personen, des Zeitpunktes, und ggf. weiterer 
anwendungsspezifischer Informationen zu erhalten. Der Betrieb des Zugriffskontrollsystems soil dabei von der Daten- 
haltung entkoppelt werden konnen. 

5 

2.4 Wesen der Erfindung 

[0077] Es werden die bekannten Sicherheits- und Authentifizierungsverfahren dergestalt kombiniert, daB zur Authen- 
tifizierung eines Datenzugriffs mehrere Personen zustimmen miissen, weitere Informationen aufgenommen werden kon- 
10 nen und die Rollen verschiedener Schritte im Authentifizierungsprozess raumlich und datentechnisch weitgehend ent- 
koppelt sind. 

[0078] Damit wird es moglich, die Verteilung der Verantwortung fiir Teilbereiche ortlich und organisatorisch zu tren- 
nen und Systeme auf unterschiedlichen Plattformen zu integrieren. 

15 2.5 Gewerbliche Anwendbarkeit 

[0079] Alleine im Gesundheitswesen wird von Fachleuten ein enormes RationaJisierungsr>otential sowie eine Quali- 
tats- und Serviceverbesserung vorhergesagt, wenn die Kommunikation zwischen mehreren Arzten, die einen Patienten 
behandeln, verbessert wird. 

20 [0080] Die elektronische Kommunikation, wie sie in vielen anderen Bereichen heute bereits iiblich ist, konnte dafur ei- 
nen wichtigen Beitrag leisten, scheiterte bisher aber an einer Infrastruktur, die einerseits die erforderlichen Sicherheits- 
anforderungen erfulit und andererseits fur die betroffenen Akteure handhabbar bleibt. 
[0081] Die beschriebene Erfindung kann als Grundlage fur diese Sicherheits-Infrastruktur dienen. 
[0082] . Weitere Anwendungsfalle ergeben sich z. B . in der Rechtspflege, der Wirtschafts- und Steuerberatung, der Per- 

25 sonalverrnittlung und -beratung, dem Versicherungs wesen, dem Handel mit Kauferprofilen oder dem Finanzwesen. 

2.6 Vorteile 

[0083] Bisherige Losungen auf bekannten Standards ermoglichen immer nur die Authentifizierung einer Person (z. B. 
30 des Arztes). Dieser hat dann Zugriff auf einen wesentlich groBeren Datenbestand, nicht nur auf den jeweiligen Patienten, 
was hier eingeschrankt werden kann. Durch die ttbertragung weiterer Kontextdaten konnen beliebig komplexe Sicher- 
heitsphilosophien implementiert werden. 

[0084] Ein weiterer Vorteil der beschriebenen Losung ist die Modularity. Es konnen damit einfach bestehende Sy- 
steme verschiedener Datenhalter und Datenverwender mit einfachen Schnittsteilen kombiniert werden zu einem sicheren 
35 Datenaustauschnetzwerk. 

2.7 Ausfiihrungsbeispiel 

siehe Abschnitt 3 

40 
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Public Key Cryptographic Apparatus and Method ("Hellman-Merkle") 
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Information Technology - Open Systems Interconnection - The Directory: Selected attribute types. 
ITU-T Recommendation X.520 
ISO/TEC 9594-6; 1997 

[X.680] Abstract Syntax Notation One (ASN.l) - Specification of Basic Notation 
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[XML] 
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W3C Recommendation; 6 October 2000 
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3.1 Vorbemerkung 

[0085] Das beschriebene Ausfiihrungsbeispiel beruht auf der konkreten Aufgabenstelliing im medizinischen Kontext 
(vgl. Erlauterungen zum Patentantrag) und verwendet deshalb die entsprechenden Begriffe "Arzt", "Patient" usw. Die zu- 
grunde liegende Aufgabenstellung besteht darin, dem Arzt Zugriff auf vertrauliche Daten des Patienten, den er gerade 
behandelt, zu gewahren, und zwar nur zu diesem Patienten und nur in einem Umfang, wie es seiner standesrechtlichen 
Zulassung und der Einwilligung des Patienten entspricht (vgl. Anspruch 1). 

[0086] Mogliche Erweiterungen und Varianten des Verfahrens sind teilweise (in Kursivdruck) im Text sowie im letzten 
Abschnitt beschrieben, ergeben sich aber insbesondere aus den Patentanspruchen. 

i 

3.2 Architektur 

[0087] Die an einem Gesamtsystem beteihgten Komponenten sind in der Zeichnung 1 skizziert 
[0088] Es wird fur die drei wesentlichen Bestandteile - Anforderungsstelle, ZugriffskontroUe und Datenhaltung - im- 
mer im Singular gesprochen. In einem ausgebauten System konnen natiirlich von all diesen Stellen mehrere Instanzen 
auftreten, die auch miteinander weiter vernetzt (z. B. iiber HTML^Links) sein konnen. 

3.2.1 Arbeitsstation zur Zugriff sanf orderung 

[0089] Am Arbeitsplatz des Arztes befindet sich ein PC mit einem Standard- Web-Browser. Es wird angenommen, daB 
der Zugriff auf die Daten vorzugsweise uber HTML/http erfolgt, da damit eine einfache Integration und Standardisierung 
erreicht werden kann. 

[0090] Erganzend kann an der Arztpraxis auch ein eigenes Praxis-Managent- System ("PMS") vorliegen, das entweder 
iiber den Browser oder unabhangig, aber sinnvollerweise auch uber http/https Daten nach Freigabe abrufen kann. Die In- 
tegration des PMS ist jedoch fur das Verstandnis der vorliegenden Erfindung unwesentlich. 
[0091] Die Zuverlassigkeit des PCs und der Praxissoftware unterliegt der Kontrolle des Arztes. 
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3.2.2 Schliisselkarten der Benutzer 

[0092] Sowohl Arzt als auch Patient verfugen iiber eine Smart-Card mit doit abgelegtem privatem Schliissel und inte- 
griertem Kryptoprozessor (nach Anspruch 7 und 8). 
5 [0093] Fur Arzte gibt es dafiir bereits einen etablierten Standard ("health professional card" - HPC), der diese \brga- 
ben erfullt 

[0094] Fiir die Patienten gibt es keinen definierten Standard. Die Karte des Patienten sei mit einem Fingerabdruckleser 
ausgestattet, der vor jeder Verschliisselungsaktion ausgelost werden mu8 und dafur sorgt, daB vor jeder Senilis selverwen- 
dung eine explizite, personliche WillensauBerung des Patienten vorliegt (Anspruch 9 und 10). 
10 [0095] Die Arbeitsstation des Arztes muB mit geeigneten Lesegeraten ausgestattet sein, um die Smart-Cards (gleich- 
zeitig oder nacheinander) anzusteuern. 

3.2.3 ZugriffskontroUsystem 

15 [0096] Das ZugriffskontroUsystem ("Access Management Hub") befindet sich raumlich und organisatorisch unabhan- 
gig von Arztpraxis und Datenbank. 

[0097] Es ist uber eine Firewall mit dem Internet verbunden. 

[0098] Es verfiigt iiber eine Datenbank der offentlichen Schliissel aller registrierten Arzte sowie aller Zertifizierungs- 
stellen, die zur Registrierung von Patienten befugt sind (Access directory). 
20 [0099] Diese Datenbank kann am Standort der Zugriffskontrollstelle selbst liegen oder iiber geeignete Directory-Pro- 
tokolle (z. B. LDAP) ganz oder teilweise von anderen Standorten importiert werden (vgl. Anspruch 21 ff). 

Erweiterung 

25 [0100] Werden - abweichend vom Bild - mehrstufige Zertifikatsketten verwendet (vgl. Anspruch 18), reicht es fur die 
priifende S telle aus, die Zertifikate der untersten Ebenen der verwendeten Ketten vorzuhalten. In diesem Fall miissen die 
vollstandigen Zertifikate einschlieBlich ggf. aller Zwischenzertifikate auf den Smartcards der zu authentifizierenden Per- 
sonen abgelegt sein und als Bestandteil des Authentifizierungsantrages mit iibertragen werden (Anspruch 20). 
[0101] Die Zugriffskontrollstelle steilt das empfindlichste System in der Sicherheitskette dar und befindet sich deshalb 

30 in einem eigenstandigen hochsicheren Bereich eines spezialisierten Dienstleisters ("Access security provider"). 

Erweiterung 

[0102] Alle Vorgange konnen - z. B. zur Beweissicherung in Streitfallen - mitprotokolliert werden ("Access Log"). 

35 

Erweiterung 

[0103] Die Zugriffskontrollstelle kann bereits Informationen vorhalten, wo welche Daten uber einen Patienten abge- 
speichert sind ("Location directory") 

40 

3.2.4 Datenspeicher 
[0104] Die Datenbank mit Patientendaten wird als bestehend angenommen. 

[0105] Die Schnittstelle fiir Fernzugriff sollte moglichst nahe an die Anforderung browsergestutzter Systeme kommen, 
45 was beispielsweise durch die Anwendung der XML- Version des intemationalen Patientendatenstandards "hl7" erreicht 
werden kann. 

[0106] Der Datenspeicher ist aus dem Internet nicht direkt erreichbar (Anspruch 39). 

3.2.5 Freigabesystem 

50 

[0107] Das Freigabesystem ("Zugriffskontrollserver") befindet sich hinter einer Firewall (Anspruch 39) am Standort 
des Datenhalters, z. B. eines Krankenhauses ("Hospital or other maintainer of health information services"). 
[0108] Im Beispiel wird angenommen, daB die Datenbank selber Informationen im XML-Format liefert, das von den 
gangigen heutigen Browsern nur eingeschrankt geiesen werden kann. In diesem Fall kann das Freigabesystem eine Uber- 
55 setzung ("XSLT-Processor") in Standard-HTML vornehmen. Es konnen aber auch XML-Daten direkt durchgereicht 
werden (nach erfolgter Freigabe) oder, wenn die Datenbank selbst HTML-Format liefern kann, kann auch dieses nach 
Prufung weitergereicht werden, Durch diese Variationsmoglichkeiten ergeben sich breite Anpassungsmoglichkeiten an 
vorhandene Systeme. 

[0109] Fiir die Implementierung kann jede gangige Prograrnmierumgebung verwendet werden. Java-Servlets bieten 
60 beispielsweise die erforderlichen HTTP-Schnittstellen und sind offen fiir die wichtigen Netzwerk-, Krypto- und XML- 
Bibliotheken. 

[0110] Der Zugriff auf den Datenspeicher erfolgt typischerweise nochmals iiber eine Paketfllterung auf IP- und Port- 
Ebene (dicke schwarze Linie mit Lochern), so daB sich das Freigabesystem in einer DMZ zwischen zwei Paketflltern be- 
findet (vgl. "Stand der Technik/Firewall" sowie Anspruch 39 und 40). Altemativ, aber mit gleicher Funktionalitat, erfolgt 
65 die Kommunikation zwischen Firewall und Datenbank uber ein anderes Protokoll als TCP/IP, so daB ein direktes Routing 
aus dem Internet effizient verhindert wird. 

[01U] Das Freigabesystem erhalt seine Zugriffskontrollinformationen aus der Datenbank (Anspruch 30 ff, im Bild an- 
gedeutet mit dem dicken Doppelpfeil), wobei die genaue Implementierung davon abhangt, wie diese Informationen vor- 
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liegen. Eine einfache Moglichkeit besteht darin, daB die Zugriffskontrollinformationen zusammen mit den Daten (An- 
spruch 32), etwa im HTML-Header als Meta-Tags (Anspruch 33) oder als spezifische Felder in einem XML-Format (An- 
spruch 34) abgelegt sind. 

3.2.6 Dateniibertragung 

[0112] Die Dateniibertragung erfolgt im Beispiel ausschlieBlich uber das Internet (vgl. Anspruch 2), also zunachst un- 
sicher. 

[0113] AUe Verbindungen werden uber ssl, also verschlusselt, realisiert (Anspriiche 16, ggf. 21, 26/27, 36). Dabei er- 
folgt immer eine wechselweise Authentifizierurig (also sowohl Server gegenuber Client als auch Client gegenuber Ser- 
ver), um einen hochstmoglichen Schutz gegenuber Angreifem zu gewahren. 

[0114] Die Ablaufe sind so gestaltet, daB das einfache http-Protokoll mit Request-Response-Zyklen ausreicht. Somit 
kann an alien Verbindungen das standardisierte https-Protokoll (http uber ssl) verwendet werden (Anspriiche 17, 27, 36). 
[0115] Erweiterungen und Variationen der Netzwerkprotokplle sind an dieser Stelle zwar denkbar, versprechen aber 
keinen funktionalen Vorteil. 

3.2.7 Trust-Center 

[0116] Im beschriebenen Ablauf sind eine Reihe von asymmetrischen Schlusselpaaren im Einsatz, und zwar minde- 
stens: 

- Schliissel des Arztes auf der HPC (Anspruch 1) 

- Schliissel des Patienten (Anspruch 1) auf seiner biometrisch gesicherten (Anspriiche 9, 10) Karte 

- ssl-Client-Schlussel des Arzt-Arbeitsplatzes (Anspruch 16 und 35) 

- ssl-Server-Schliissel des Zugriffskontrollsys terns (Anspruch 16 und 26) 

- ssl-Server-Schliissel des Freigabesystems (Anspruch 26 und 35) 

- ssl-Client-Schliissel des Zugriffskontrollsystems (nach Anspruch 24 und 26) und/oder des Freigabesystems (nach 
Anspruch 25 und 26) 

[0117] Diese Schliissel werden sinnvollerweise von einem Trust-Center als spezialisiertem Dienstleister generiert und/ 
oder in ihrer Echtheit bestatigt (Anspruch 10). Inwieweit hierbei ein einziges Oder mehrere Trust-Center verwendet wer- 
den, und ob diese organisatorisch an einer der dargestellten Stellen, z. B. der Zugriffskontrollstelle, angelagert sind, ist 
aus technischer Sicht nicht von Belang. 

3.3 Ablauf aus Benutzersicht 
3.3.1 Antragssoftware 

[0118] Wenn der Arzt seine Behandlung aufhimmt, ladt oder aktiviert er eine geeignete "Antrags-Software" (z. B. ein 
im Browser lauffahiges Java- Applet; "Authorisierungs- Applet" im Bild), die auf seinem Rechner vorinstalliert ist oder 
die er aus einer vertrauenswurdigen Quelle (z. B. auch der Zugriffskontrollstelle) beziehen kann. 

3.3.2 Freigabeantrag 

[0119] Die Antragssoftware verlangt nun nach den Identitatsbeweisen, also etwa den Smart-Cards von Arzt und Pa- 
tient. Die endgiiltige Zustimmung (nach Anspruch 1) erfordert noch die I*reigabe des Schlussels auf den Karten, z. B. 
durch ein Passwort bei der HPC und durch den Fingerabdruck bei der biometrischen Patientenkarte. 
[0120] Nach Absenden des Freigabeantrags (nach Anspruch 3) an die Zugriffskontrollstelle meldet diese entweder ei- 
nen Authentifzierungsfehler oder einen Hyperlink zum nachsten Schritt. 

[0121] Der in Zeichnung 2 auf Seite 52 dargestellte Bildschirmabzug zeigt eine Pilotversion eines solchen Freigabe- 
applets, bei dem die Smart-Cards durch Binarsequenzen ersetzt sind, die uber die Windows-Zwischenablage in entspre- 
chende Fenster eingefugt werden ("paste doctor's/patient's key here"). 

[0122] Die Freigabe selbst erfolgt in der Pilotversion durch Passworter, was im Bild beim Patienten bereits erfolgt ist 
("open") und fur den Arzt. noch abgefragt wind ("please enter password") 

3.3.3 Datenauswahl 

[0123] Im Beispiel wird angenommen, daB die Zugriffskontrollstelle bereits uber eine Liste von zum Patienten verfug- 
baren Daten verfiigt. In diesem Fall kann an den Arbeitsplatz des Arztes eine entsprechende Liste als HMTL-Seite mit 
Hyperlinks versandt werden, wobei die Hyperlinks auf die jeweiligen Freigabeserver verweisen. 

[0124] Arzt und/oder Patient wahien (ggf. gemeinsam) die abzurufenden Daten aus ("weitere Kontextinformauonen" 
nach Anspruch 1). 

3.3.4 Datenabruf 

[0125] Im Idealf all yerhalt sich das nun geoffhete System gegenuber dem Arzt wie ein Satz yon HTML-Seiten, er kann 
also im Bestand der Patientendaten mit seinem Web-Browser "surfen" (Anspruch 41 ff) und ggf. wichtige Informationen 
in sein eigenes Praxisdatensystem "downloaden". 

I 
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Erweiterung 

[0126] Bei geeigneter Datenstruktur konnen dabei auch Querverweise zwischen verschiedenen Datenbestanden auf tre- 
ten. Ggf. wird das System nach einer emeu ten Authentifizierung verlangen, wean etwa der Bereich einer anderen Zu- 
griffskontrollstelle betreten werden soil oder der Patient weitergehende Freigaberechte fur besonders vertrauenswiirdige 
Daten oder weitere Rechte (z. B. Schreibzugriflf) erteilen soli. 

3.4 Zusammenspiel der kryptographischen Komponenten 

[0127] Die erforderlichen kryptographischen Ablaufe sollen bei erfolgreicher Authentifizierung weitgehend im Hinter- 
grund ablaufen. Lediglich bei einem Authentifizierungsfehler sollen Fehlermeldungen soweit aussagefahig sein, daB Be- 
dienungsfehler behoben werden konnen. AUerdings durfen Fehlermeldungen keine wertvollen Informationen an poten- 
tielle Angreifer offenbaren oder bereits vertrauenswiirdige Daten (bzw. deren Existenz) preisgeben (falsch ware z. B. 
"Sie sind nicht berechtigt, auf den Datenbestand der Sucht-Heil-Klinik zuzugreifen"). 

3.4.1 SchliisseL 

[0128] Das Format der Schlussel entspricht dem X.509-Staridard, wie es von gangigen Internet-Browsern verstanden 
wird. (Beispiel: siehe Zeichnung 3 ) 

[0129] Die Schlussel fur https mussen dabei direkt vom Browser verstanden werden konnen. Fur die Smart-Card- 
Schlussel ist dies nicht unbedingt notwendig, da sie uber die Authentifizierungssoftware angesprochen werden. Die Ver- 
wendung standardisierter Formate ermoglicht aber den Zugriff auf vorhandene, getestete Softwarebibliotheken zur Er- 
zeugung und Verarbeitung der kryptographischen Daten. 

[0130] Ein Schliisselpaar, das aus einem Browser im PKCS#12-Format ([PKCS12]) exportiert wird, stellt sich zu- 
nachst folgendermaBen dan 



BEGIN RSA PRIVATE KEY 

Proc-Type : 4 , ENCRYPTED 

DEK-Info: DES-EDE3-CBC, FD4DC0A4 919C7342 

nrno^ ^? * GHly3 9A ^ yE/se7 kyaZa I VodgQI 7 Yl /dGBKX/pe JEwmt wkQMXl V 
BG02Jwyeo*nWcYM6t0hFAmRX^^ 

kVzbZMxunLPYQS5FekxLn8K7Ce/WKXEuniTvLGlVaAd6mhE9vKrai^ 
F2LOur/Yg5gX8cLkC9L6cY7B8LSJ5z5C9HJG3F4553o- 

END RSA PRIVATE KEY 

Bag Attributes 

friendlyName: Benjamin Blymchen's IP-Web ID 

localKeylD: 3C E3 30 30 57 B7 49 A9 CI A8 AA CO 04 B3 48 CC EC FS ?4 n? 

^f^^ G ^ = g^^^:^: W ^/OU=demo/CN=IP-Web Demo Patients CA 
^^^ C S^ 2gAwlBAgIEOrTu ' J 3 ANB g k q hki G9w0BAQQFADBeMQswCQYDVOOGEwJk 

225 aFW ° WMzAzMT, 3y Mz U5MDBaMIGCMQswCQYDVQQGEwJkZTEMMAoGAlUECBMDcHBw 
»^ QYW °2 HE ^ C * WJiZXJi2XJ ^^ 

hPv^v^?K 3 = yZW ^° 2W5kZXIgRWxlZmFudGVuMRow GAYDVQQDFBFCZW5q^^ 
a£5£ b *2 7 "^ +pBNUoGgnM/YVFelihLK 3 v af8D0pMhI6iopqfb S bTXPDP87YTsBdV ' 

24?KFsP/SSg- bl 1Z ° j iu3Y5Dfc bp7a JWbecYnt / j qrr7EGrC902TaU 



-END CERTIFICATE- 



[0131] Die wesentlichen Komponenten sind der private Schlussel ("BEGIN/END RSA PRIVATE KEY") sowie das 
X.509-Zertinkat mit dem offentlichen Schlussel ("BEGIN/END CERTIFICATE"). Beide Bestandteile sind in der Dar- 
stellung base-64-kodiert, was jedoch nur der ttbertragbarkeit binarer Daten und nicht der Zugriffssicherheit dient. Die 
weiteren Angaben dienen nur der internen Organisation des PKCS- 12-Formates. 

[0132] Dieses Format entspricht im Wesentlichen auch der intemen Darstellung auf einer Smart-Card. 

[0133] Das Zertifikat, das die Echtheit des Schliissels durch Trust-Center bestatigt, hat (nach base-64-Dekodierung) 

folgende Struktur (nach [X.509]). 
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Certificate: 
Data: 

Version: 3 (0x2) 

Serial Number: 984936122 (0x3ab4eeba) 
Signature Algorithm: mdSWithRSAEn crypt ion 

Issuer: Ode, ST=derao, 0=IP-Web,. OU=demo, CN=IP-Web Deno Patients CA 
Validity 

Not Before: Mar 18 00:00:00 2001 GMT 
Not After : Mar 18 23:59:00 2003 GMT 
Subject: C=de, ST-ppp, L=Bibberberg, 

0=lnteressenvereinigung sprechender Elefanten, 
CN^Benjamin BINxFCmchen 
Subject Public Key Info: 

Public Key Algorithm: rsaEncryption 
RSA Public Key: (512 bit) 
Modulus (512 bit) : 

00:e0:9c*: 67 : da : 67 : le : 98 : 3 6 : da : cl : 9f : 68 : aC:9b : 
62:f4:12:96:8d:6d:23:bb:50:13:3e:a4:13:54 :a0: 
6a:a7: 33 : f 6 : 15 : 15 : ed : 62 : B 4 : b2 : 81 : bd : a7 : f c : Of : 
4a: 4c: 84 : 8e:a2 :aa: 9a: 9f : 6e:c6:d3:5c:f0:cf : f3 ; 
bc:93:b0:17:55 
Exponent: 65537 (0x10001) 
Signature Algorithm: mdSWithRSAEn crypt ion 

cl : 2 f : 9f : 52 : b8 : a7 : b8 : 61 : 7 3 : 2.9 : de : 84 : d3 : 97 : c7 : aa : Od : a8 : 
eO : cf : 88 : 9e : 70 : 3a : cc : 95 : f 7 ; 6 b : b4 : 58 : 7 9 : f c : 62 : 8c : 05 : bO : 
41:2f :6a: 08 :b4: 27:30 :9d: 37 :6a: 20: 9d:b2 :91:4b: e5: 65:47: 
dd:02:9b:01:75:87:74:92:6c:8c:e4:93:b6:3f : f 9 : a5 : 4a : 9a : 
f9:al:8b:d5:7d:12:38:dl:3d:lf :9d:5f :e8:3c:d7:a0:50:db: 
d7:56:4e:8e:25:37:63: 90:e4 : 6e : 9e :da : 25 : 66 : de : 71 : 89 : ed : 
fe:3a:ab:af :bl:06:ac:2f : 4e:d9:36:94 : db : 8d : 4a : 16 • c3 • f f • 
9c: 38 



10 
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20 



25 



30 



- "Subject" ist dabei der Name der zu identifizierenden Person 35 

- "issuer" das Trust-Center, das die Echtheit bestatigt (vgl. Anspruch 10a). 

' - Validity (Gultigkeitsdatum) und Seriennummer sowie Version und Algorithrnen sind weitere Organisationsbe- 
standteile nach X.509 

- Der offentliche Schlussel ("RSA public Key") ist wesentlicher Bestandteil des Zertifikats 

- Die Signatur (eingeleitet mit der Angabe des Algorithmus), die die Echtheit des Schliissels bestatigt, schlieBt das 40 
Zertifikat ab. 

[0134] Der private Schlussel ist in einem passwortgeschutzten "Key Bag" untergebracht, d. h. zusatzlich.zur base-64- 
Dekodierung ist noch eine Entschliisselung mit dem Passwort erforderlich. 

[0135] Erst nach Offnen des "Key Bag" durch Pass worteingabe (oder Fingerabdruck) erofifnet sich die interne S truktur 45 
des privaten RSA-Schliissels, wie er zur Verwendung erforderlich ist: 



50 



55 



60 



65 
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to 



15 



20 



25 



30 



35 



40 



Enrer PEM pass phrase: 

Private-Key: (512 bit) 

modulus: 

00:e0:9c:67:da:67; 
62:f4:12:96:8d:6d: 
6a:a7: 33:f6:15:15: 
4a: 4c: 84 : 8e: a2 : aa : 
be: 93:b0: 17: 55 

publicExponent : 65537 

privateExponent : 

00:ae:e8:bd:6a:f3: 
73:ac:73:89:2f :ea: 
ca:0b: 17:53:ld:3e: 
23:28: lb:7c: 9f:b6: 
eb:e8:be:b4:21 

prime 1 : 

CO : f 5 : Ob : 2c : 25 : 3d: 
03:2e:d8:3c:85:cb: 
0a:5d:c9 

prime2 : 

00 : ea : a7 : 5b: lc: d3 : 
f3:cd:e6:4b:3d:5b: 
c2:43:2d 

exponentl : 

00:d2:3b:c2:a5:34: 
d6:5a:43:75:31:89: 
7a: ce: 59 

exponent2 : 

2f :06:a7:ld:d9:d3: 
ea:57:b2:d0:73:0e: 
3b:69 

coefficient : 

49:09:37:c9:09:26: 
a6:41:32:fe:21:a7: 
74 :60 



:le:98:36:da: 
:23:bb:50:13: 
:ed:62:84:b2: 
:9a:9f :6e:c6: 

(0x10001) 

60:7c:d2:42: 
ec:a7: 62:2d: 
d2:a4 :3c:81: 
8e:2a:eb:49: 



a3:95: If :9b: 
6c:50:00:le: 



a0:73:cc:3a: 
3c:f6:bl:37: 



cl:9f : 68:ac:95 
3e:a4 : 13: 54 :a0 
81:bd:a7:fc:0f 
d3:5c:f0:cf : f 3 



ba:03:04:05:59 
0a:5b:c4:fd:e2 
93:4d:89:82:37 
e3:b5: fl:cl:18 



ee:8b:83:b2: 57: 
57:a7: la:37: f 4 : 



63:ca:33:73:e2: 
37:98:4e:34:3d: 



cb : f a : ee : 02 : 
04:a5:62:64: 



98:21:5f :ba; 
7e:a9: f 9:54 : 



23:d4:le:9c: 
6e: 07:21 :c9: 



97:57:a5:26:c5; 
a5 :e9 : lc: ea : 72 : 



4b:f 5:8f :cd: f 5: 
ec:f 3:0f :49: 29: 



58:b4 :eb:ll: 38: 
4b:34:57:ll:43: 



[0136] Fiir Schliissel, die auf Smart-Cards abgelegt sind, ist diese Struktur des privaten Schlussels von auBen nicht zu- 
ganglich (auch nicht nach Freigabe). Alle zu verschliisselnden Daten miissen in die Smart-Card ubertragen werden, wer- 
den dort (nach Freigabe) verschliisselt und wieder aus der Smart- Card ausgelesen. 

3.4.2 Authentifizierungs- Applet 

[0137] Das Authentifizierungs^- Applet ubernimmt folgende Funktionen: 



45 - Erstellen eines zufallig generierten Session Keys (Anspruch 4 und 11) 

- Ermitteln der aktuellen Systemzeit (fiir Anspruch 4) 

- Ermitteln der Identitat von Arzt und Patient (Anspruch 1 - z. B. "Distinguished Names" nach X500 bder spezielle 
Arzt-/Patientenindices) 

- Abfragen der Zustimmung von Arzt und Patient (Anspruch 1) 

50 - bei Erteilung der Zustimmung: Verschlusselung des Session Keys mit dem jeweiligen privaten Schliissel von 

Arzt und Patient (Anspruch 5 und 6 sowie 12) 

- Zusammenfiigen der Komponenten zu einem Session-Request (nach Anspruch 3 ff) 

- Signieren des Session-Request mit dem (unverschliisselten) Session- Key (Anspruch 13) 

55 [0138] Erweiterung: 

Wenn der https-Clienf-Schliissel im Session-Request ubertragen werden soil, so muB das Applet diesen vom Browser ab- 
rufen (Anspruch 14 ff, insbesondere 17) 
[0139] Erweiterung: 

Gegebenenfalls werden noch weitere Informationen zur Spezifikation des Kontextes, wie in Anspruch 1 angefiihrt, an- 
60 gegeben 

[0140] Erweiterung: 

Das X.509-Zertifikat einer an der Authentifizierung beteiligten Person (oder mehrerer Personen), ggf. auch zugehorige 
Zertifizierungsketten, konnen ebenfalls im Antrag mit aufgenommen werden (Anspruch 20). In diesem Fall braucht beim 
Zugriffskontrollsystem nur das entsprechende Wurzelzertifikat vorgehalten werden (vgl. Anspruch 19). Damit wird die 
65 Verantwortung, die Berechtigung einer Person, das System generell zu benutzen, zu priifen, von der Zugriffsprufstelle an 
das Trust-Center abgegeben. 
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3.4.3 Session-Request 

[0141] Der erstellte Session-Request (s. Anspruch 3 ff) hat im Beispiel foigende Struktur (ohne X.509-Zertifikate nach 
Anspruch20): 

.5 



X-+-0-+-0 
- 1 +-0 


. 0-+- 
+- 


0.0.0 
0.0.1 


— 


Session ID 254 bit random 
Session time Stamp 

encrypted Session key (DESede x dccPK x patPK) 










1 +-0 

I 


. 2~ + - 
+- 
+- 
+- 


0.2.0 
0.2.1 
0.2.2 
0.2.3 


— 


Doctors Data: 
Subject DN 
Issuer DN 
Serial Number 
Fingerprint 




1 +-0. 


3-+- 
+- 
+- 
+- 


0.3.0 
0.3.1 
0.3.2 
0.3.3 




Patients Data: 
Subject DN 
Issuer DN 
Serial Number 
Fingerprint ' 




1 +-0. 


4-+- 
+ - 


0.4.0 
0.4.1 




SessionlDblock 
SessionlDblock 


signed (docPK) 
signed ( pa tPK) 


+-!---- 


Bag Seal: MD5 


of 0 encrypted 


with session Key 
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[0142] Diese Struktur kann z. B. in ASN.l (siehe [X.680]) dargestellt werden, in Base 64 kodiert und dann als Query 30 
an eine URL angefugt und so via http(s) an das Zugriffskontrollsystem ubertragen werden. 

3.4.4 Authentitatspriifung durch das Zugriffskontrollsystem 

[0143] Das Zugriffskontrollsystem dekodiert die query: 35 
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65 
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raw DER-Structure as Hex-Dimp: 

00 01 02 03 04 05 06 07 - 08 09 OA OB OC OD OE OF 0123456789ABCDEF 



10 



15 



20 
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30 



35 



40 



45 



00000000 


30 


82 


02 


67 


30 


82 


02 


51 


00000010 


30 


97 


3C 


14 


20 


F2 


OB 


12 


00000020 


70 


E3 


5F 


AC 


D< 


35 


BA 


67 


00000030 


30 


31 


30 


34 


30 


32 


31 


31 


00000040 


30 


04 


40 


02 


F2 


43 


E7 


9F 


00000050 


81 


BB 


AO 


69 


6E 


DC 


5D 


OB 


00000060 


3D 


48 


34 


BA 


25 


EB 


2D 


F3 


00000070 


97 


FA 


25 


BB 


5D 


41 


5F 


44 


00000080 


AB 


AD 


39 


30 


81 


9A 


13 


47 


00000090 


6E 


20 


4A 


6F 


68 


6E 


73 


65 


0000O0A0 


6D 


65 


69 


6E 


73 


63 


68 


61 


OOOOOOBO 


73 


20 


4A 


56 


58 


2C 


4C 


3D 


00OOOOCO 


73 


65 


6E 


2C 


53 


54 


3D 


62 


00O0O0D0 


37 


43 


4E 


3D 


49 


50 


2D 


57 


00O0O0EC 


44 


6F 


63 


74 


6F 


72 


73 


20 


OOOOOOFO 


6D 


6F 


2C 


4F 


3D 


49 


50 


2D 


00000100 


65 


6D 


6F 


2C 


43 


3D 


64 


65 


00000110 


5E 


"9A 


5F 


89 


C9 


CO 


AE 


01 


00000120 


30 


81 


AF 


13 


5B 


43 


4E 


3D 


00000130 


20 


42 


6C 


3F 


6D 


63 


66 


65 


00000140 


72 


65 


73 


73 


65 


6E 


76 


65. 


00000150 


67 


20 


73 


70 


72 


65 


63 


68 


00000160 


65 


66 


61 


6E 


74 


65 


6E 


2C 


00000170 


62 


.65 


72 


67 


2C 


53 


54 


3D 


00000180 


13 


38 


43 


4E 


3D 


49 


50 


2D 


00O001SO 


20 


50 


61 


74 


69 


65 


6E 


74 


000001AO 


64 


65 


6D 


6F 


2C 


4F 


3D 


49 


00O0O1BO 


3D 


64 


65 


6D 


6F 
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[0144] Daraus ergibt sich die ASN.l-Struktur, die die Komponenten des Session-Requests offenlegt (vgl. ASN.l- 
Struktur wie oben angegeben): 



50 



55 



60 



65 



18 



DE 101 21 819 A 1 



ASNl-Structure of Request: 

0:d=»0 hl=4 1= 615 cons: SEQUENCE 
4:d=l hl=4 1= 5 93 cons: SEQUENCE 
8:d=2 hl=2 1= 55 cons: SEQUENCE 
10:d=3 hl=2 1= 32 prim: OCTET STRING 

44:d=3 hl=2 1= 19 prim: GENERALIZE DTI ME : 20010402 115953+0200 

65:d=2 hl=2 1= 64 prim: OCTET STRING 
131:d=2 hl=3 1= 154 cons: SEQUENCE 
134:d=3 hl=2 1= 71 prim: PRINTABLESTRING : 
CN=Johann Johns eder, 

0=Gemeinschaf tspraxis JVX, L=Anderhausen, ST=bbb, 0=de 
207:d=3 hl=2 1= 55 prim: . PRINTABLESTRING : 

CN=IP-Web Demo Doctors CA, OU=demo, 0=IP-Web, ST=demo, C=de 
264:d=3 hl=2 1= 4 prim: INTEGER :3AB4EC35 

270:d=3 hl=2 1= 16 prim: OCTET STRING 

288:d=2 hl=»3 1= 175 cons: SEQUENCE 
291:d=3 hl=2 1= 91 prim: PRINTABLESTRING : 

CN=Benjamin Bl?mchen, 

0=lnteressenvereinigung sprechender Elefanten, 

L=Bibberberg, ST=?pp, C=*de 
384:d=3 hl-2 1= 56 prim: PRINTABLESTRING : 

CN=IP-Web Demo Patients CA, 0U=deino, 0=*IP-Web, ST=demo, C=de 
4 42:d=3 hl=2 1= 4 prim: . INTEGER : 3AB4EEBA 

44 8:d=3 hl=2 1= 16 prim: OCTET STRING 
4 66: d=2 hl=3 1= 132 cons: SEQUENCE 
469 : d=3 hl=2 1= 64 prim: OCTET STRING 
535:d=3 hl=2 1= 64 prim: OCTET STRING 

601:d=l hl=2 1= 16 prim: OCTET STRING 
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[0145] Es liegen nun dielnformationen vor, um die Uberprufung der Authentizitat vorzunehmen: 

- aus den Identitatsinformadbnen von Axzt und Patient sowie deren Zertifizierem werden die entsprechenden Zer- 
tifikate ermittelt 

- tJber Seriennummer und Fingerprint der Zertifikate wird ein erster Echtheitstest vorgenommen (Anspruch 18) 35 

- Die Zertifikate enthalten den jeweiligen offentlichen Schlussel 

- der verschiusselt vorliegende Session Key wird mit den beiden offentlichen Schlusseln von Arzt und Patient ent- 
schlusselt (Anspruch 12): 

Dann und nur dann wenn sowohl Arzt als auch Patient mit dem richtigen privaten Schlussel gearbeitet haben, lafit 
sich so der urspriingliche Session Key wiederherstellen 40 

- Es wird der Hash-Wert des Session-Requests gebildet und mit dem wiederhergestellten Session Key verschius- 
selt. Wenn das Ergebnis mit dem ubermittelten Wert ("Bag Seal") identisch ist, client das als Beweis fur eine kor- 
rekte Authentirizierung (Anspruch 13) 

[0146] Der so wiederhergestellte Session Key kann bei Bedarf weiter verwendet werden, um die weitere Kommunika- 45 
tion zu verschliisseln, so daB nur die berechtigten Parteien daran teilnehmen konnen (Anspruch 15). 
[0147] Erweiterung: 

Das Zugriffskontrollsystem kann den ssl-Schllissel des Clients aus der Netwerksoftware abrufen, wenn diese Informa- 
tion nicht Bestandteil des Session-Requests ist. Damit entfallt clientseitig die Notwendigkeit, daB das Applet auf den 
https-Schlussel zugreifen muB. Dies wiederum vereinfacht die Verwendung von Standardbrowsern auf Clientseite. 50 

3.4.5 Freigabeserver 

[0148] Der entschlusseite Session-Key, die ssl-Identitat des PC in der Arztpraxis und die anderen Informationen des 
Session-Requests werden an den Freigabeserver (nach Anspruch 23) ubermittelt. Hierzu kann z. B. das Zugriffskontroll- 55 
system eine https- Verbindung zu diesem aufbauen (vgl. Anspruch 24, 26, 27). Der Freigabeserver speichert die Informa- 
tionen, um sie fiir den Fall eines Datenabrufs auswerten zu konnen. 

[0149] Daraufhin ubermittelt das Zugriffskontrollsystem eine Erfoigsmeldung an den Browser beim Arzt, die sinnvoll- 
erweise einen Hyperlink auf den Freigabeserver (bzw. je einen Link auf jeden Server, wenn Datenbestande an verschie- 
denen Stellen vorliegen) enthalt. AuBerdem konnen die Links (gemaB Anspruch 28 und 29) Query- Variablen enthalten, 60 
die zur weiteren Spezifikation der verlangten Daten dienen (z. B. Namen des Patienten, um Verwechslungen bei kurz 
aufeinanderfolgenden Abfragen zu vermeiden). 

[0150] Durch Aktivieren der Links im Browser (Anspruch 41 ff) sendet das Arztsystem nun einen http(s)-Request an 
den Freigabeserver. Dieser ruft die gewiinschten Daten aus der Datenbank ab und erhalt von dieser (ggf. auch vorher) die 
fur den Zugriff erforderlichen Voraussetzungen (Anspruch 30 ff). Diese Voraussetzungen vergleicht er mit den gespei- 65 
cherten Daten aus dem vorher ubermittelten Session-Request (Anspruch 30). 

[0151] Des weiteren ermittelt der Freigabeserver die ssl-Identitat des Arzt-PC und vergleicht sie mit der vom Zugriffs- 
kontrollsystem ubermittelten (Anspruch 35, 36). Damit wird verhindert, daB ein unbefugter Benutzer mit einer aufge- 
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zeichneten Zugriffssequenz, die er zwar nicht analysieren, aber 1 : 1 wiedergeben kann, Datenzugriff erhalt ("replay-at- 
tack"). 

[0152] Wenn alle Priifungen erfolgreich sind, ubertragt der Freigabeserver die erbetenen Daten als http(s)-Response an 
den Arzt-PC. Dieser Response kann weitere Hyperlinks zu anderen Daten auf dem. gleichen oder einem anderen System 
5 enthalten (Anspruch 41 ff). Sofem fur einen Abruf bestimmte Inhalte einer URL-query erforderlich sind, werden diese 
im Response weitergereicht ("state-Management" im http-Protokoll, vgL auch Anspruch 28 und 29). 

3.5 Erganzungen und Erweiterungen 

10 [0153] Wichtige Variationen der Erfindung, die hier im Ausfiihrungsbeispiel nicht oder nur andeutungsweise erfaBt 
sind, werden im Folgenden noch angefiihrt. 

3.5.1 Komplexe Verschiusselung in der Datenubertragung 

15 [0154] Im beschriebenen Beispiel erfolgt die Ubertragung zwischen freigebender S telle iiber https, also verschiiisselt 
mit dem ssl-Client-Schliissel des Arzt-PC. Dieser Schliissel ist iiblicherweise auf dem Rechner in einer Datei abgelegt 
und ist damit unbefugten Zugriffen z. B. bei der Rechneradrninistration ausgesetzt ("man-at-the-end-attack"). Dieser 
Schliissel bietet also bei weitem nicht die Sicherheit wie die Smart-Card-basierteh Schliissel zur personlichen Authenti- 
fizierung. 

20 [0155] Alternative Schliissel, die diesen Mangel beheben konnen, sind in Anspruch 37/38 beschrieben. Insbesondere 
der Session Key kame hierfiir in Frage. Die meisten dieser Losungen haben jedoch den Nachteil, dafi clientseitig keine 
Standardbrowser mehr verwendet werden konnen. 

3.5.2 Schreibender Datenzugriff 

25 

[0156] Die bisherigen Beschreibungen des Ausfuhrungsbeispiels beziehen sich teilweise implizit auf lesenden Zugriff. 
[0157] Die Ablaufe fur schreibenden Zugriff (Daten anlegen, andern, loschen, Rechte andern) sind weitgehend iden- 
tisch. Lediglich der Freigabeserver und die Kommunikation mit der Datenbank mu8 entsprechend angepaBt werden. Als 
Kommunikationsprotokoll mit dem Client kann weiterhin http(s) verwendet werden, das durch Formulare und POST-Re- 
30 quests eine Dateneingabe ermoglicht. 

3.5.3 Verzeichnisdieriste fur Zertifikate 

[0158] Das beschriebene Ausfiihrungsbeispiel geht nicht darauf ein, woher die Zertifikate kommen, die fur die Authen- 
35 titatsiiberprufung eingesetzt werden. Neben der Ubermittlung mit dem Session Request nach Anspruch 20 sind die Va- 
riationen in Anspruch 21 und 22 dargelegt. 

[0159] Eine sinn voile Moglichkeit ware etwa, wenn die Ausgabe der Smart-Cards von einem Trust-Center erfolgt, das 
nicht nur die Identitat des Inhabers, sondern auch weitergehende Voraussetzungen zur Teilnahme am System (z. B. bei 
einem Arzt die fachliche Zulassung) priift und festhalt. Diese Informationen konnen dann - zusammen mit dem Zertifikat 
40 - von diesem Trust-Center iiber LDAP (ggf. iiber eine gesicherte Verbindung) dem Zugriffskontrollsystem ubermittelt 
werden. 

[0160] Bei einem Ausbau des Systems konnen mehrere unabhangige Stellen diese Zertifizierung ubernehmen (z, B. 
Krankenkassenfilialen fur Patienten). In diesem Fall empfiehlt sich ein mehrstufiges Zertifzierungsverfahren, wie es in 
[X.509] vorgesehen und in Anspruch 18 ff angefiihrt ist. 

45 

3.5.4 Verzeichnis der verfugbaren Daten 

[0161] Die beschriebene Realisierung geht davon aus, daB letztlich erst das datenhaltende System detaillierte Informa- 
tionen besitzt, welche Daten zu einem spezifischen Kontext zur Verfugung stehen. 
50 [0162] Diese Information kann aber auch anders iiber die einzelnen Systemkomponenten (Zugriffskontrolle, Freigabe, 
mehrere datenhaltende Stellen, dedizierte Verzeichnisse) verteilt werden. Auch eine Kombination mit anderen Datenbe- 
standen (Verzeichnisdienst nach vorgehendem Abschnitt, Zugriffskontrolliste) ist denkbar. 

[0163] Die detaillierten VariationsmogUchkeiten des Datenbankdesigns ergeben sich aus praktischen und sicherheits- 
politischen Erwagungen und gehen iiber den in diesem Patent beanspruchbaren Rahmen hinaus. 

55 

3.5.5 Iterative Zustimmung zur Datenfreigabe 

[0164] In der Zeichnung zum Gesamtsystem ist ein "Selection Key" angedeutet, der verwendet wird, wenn der Patient 
explizite Zustimmung zur Offenlegung einer beschrankten Teilauswahl aus alien verfugbaren Informationen erteilen 
60 soil. In den weiteren Erlauterungen wurde aus Griinden der Obersichtlichkeit hierauf nicht weiter eingegangen. 

[0165] Hierbei handelt es sich um kontextspezifische Informationen (nach Anspruch 1), die durch mehrere Anforde- 
rungszyklen (nach Anspruch 41) ermittelt werden. 

[0166] Der Selection Key iibernimmt dabei die Rolle des Session Key; es wird gleichsam durch Iteration nach An- 
spruch 41 ein neuer Kontext nach Anspruch 1 eroffnet. 

65 

3.5.6 Vertretung von Personen 
[0167] Anspruch 45 erwahnt verschiedene Vertretungskonstellationen. Beispiele hierfur konnen sein: 
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- nicht ein Arzt selber, sondern ein Assistent ruft Daten ab 

- Patienten werden von Erziehungsberechtigten oder einem \brmund vertreten 

- Ein "Notzugang" ermoglicht den Zugriff auf Daten von Patienten ohne BewuBtsein 

- Zugriffsrechte werden nicht einer Person, sondern einer Organisation gewahrt 

- ZugrifTsschlussel konnen in einer Software, z. B. der Praxissoftware des Arztes, hinterlegt sein 

- Applikationen in anderem als dem hier beispielhaft dargestellten Kontext konnen andere Vertretungsmoglichkei- 
ten beinhalten 

[0168] Welche Vertretungsmoglichkeiten zugelassen sind ist eine Frage der Sicherheitspolitik. 

3.5.7 Festlegung einer Sicherheitspolitik 
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[0169] Viele Entscheidungen tiber die Implementierung konnen nicht nach technischen Erwagungen auf der Suche 
nach einer "bestmoglichen Sicherheit" getroffen werden, sondern entstehen durch Abwagung zwischen Sicherheitstech- 
nik, rechtlichen Anforderungen, Kompatibilitat mit bestehenden Systemen oder Bedienbarkeit. Selbst subjektive Ver- 15 
trauens-'^efuhle" miissen hier mit einbezogen werden. Diese Erwagungen entziehen sich naturgemaB der technischen 
Natur eines Patentes, weshalb in dieser Beschreibung derartige Entscheidungen und Varianten regelmaBig offen gelassen 
werden. 

[0170] Aufbauend auf dem hier beschriebenen Grundgeriist konnen Anpassungen an eine vorgegebene Sicherheitspo- 
litik - bei gegebenen Anforderungen - durch einen geubten Fachmann vorgenommen werden. 20 

Patentanspruche 

1. Verfahren zur Zugriff steuerung auf elektronisch gespeicherte Daten in verteilten heterogenen Umgebungen, ge- 
kennzeichnet dadurch, daB 25 
die Freigabe des Datenzugriffs durch mehrere Personen erfolgt 

eine dritte Stelle zur Freigabepriifung zwischen Datenabrufstelle und Datenspeicherstelle eingeschaltet ist 

fur die Uberpriifung der Authentizitat der Freigabe erteilenden Personen kryptographische \erfahren mit offentli- 

chen und privaten Schlusseln verwendet werden 

die Kontextsituation der Personen im Rahmen der Datenanforderung mit in den Umfang der erteilten Freigabe ein- 30 
flieBen kann. 

2. Verfahren nach Anspruch 1, gekennzeichnet dadurch, daB 

fur die Datenubertragung geeignete Netzwerkprotokolle verwendet werden konnen, 

fur die Datenubertragung die Intemet-Protokoll-Familie (insbesondere IP, TCP, UDP) verwendet werden konnen, 

fur die Datenubertragung das Internet verwendet werden kann. 35 

3. Verfahren nach Anspruch 1, gekennzeichnet dadurch, daB fur jeden Vorgang, bei dem eine Freigabe angefordert 
wird 

ein spezielles digitales Freigabeobjekt ("Authentifizierungsantrag") zur Kommunikation der beteiligten Systeme 
untereinander erstellt wird 

das Freigabeobjekt ein eindeutiges Merkmal des Authentiflzierungsvorganges enthalt 40 
das Freigabeobjekt weitere Daten iiber den Authentifizierungskontext enthalten kann 

4. Verfahren nach Anspruch 3, gekennzeichnet dadurch, daB 

das Freigabeobjekt einen zufallig generierten oder anderweitig als eindeutig geltenden digitalen Schliissel zur Iden- 
tifikation des Authentifizierungsvorgangs enthalten kann 

das Freigabeobjekt einen Zeitstempel des Authentifizierungsantrages enthalten kann 45 
das Freigabeobjekt Angaben uber den zeitlichen Geltungsbereich der Authentifizierung enthalten kann 

5. Verfahren nach Anspruch 1 , gekennzeichnet dadurch, daB die am Authentifizierungskontext beteiligten Personen 
durch asymmetrische digitale Schlusselpaare identifziert sind 

6. Verfahren nach Anspruch 5, gekennzeichnet dadurch, daB eines der folgenden Verfahren fur die asymmetrischen 
digitalen Schliissel verwendet wird: 50 
RSA 

DSA 

elliptische Funktionen 

7. Verfahren nach Anspruch 5, gekennzeichnet dadurch, daB der private Schliissel einer an der Authentifizierung 
beteiligten Person auf einer physikalisch eigenstandigen Einheit gehalten wird, die 55 
von der Person mitgefuhrt werden kann 

vom System, das an der Datenabrufstelle zur Anforderung der Datenfreigabe verwendet wird, gelrennt werden kann 
mit unterschiedlichen Systemen zur Anforderung der Datenfreigabe verwendet werden kann 

die erforderiichen Verschlusseiungsoperationen selbst vornehmen kann, so daB der private Schliissel der Person 
nicht an das System zur Anforderung der Datenfreigabe iibertragen werden muB 60 

8. Verfahren nach Anspruch 7, gekennzeichnet dadurch, daB diese' eigenstandige Einheit eine handelsubliche 
Smart-Card (integrierter Schaltkreis, eingebaut in ein Kunststoffgehause im Scheckkartenformat) mit Kryptopro- 
zessor ist 

9. Verfahren nach Anspruch 5 bis 8, gekennzeichnet dadurch, daB der private Schliissel durch ein biometrisches 
Merkmal vor unbefugter Verwendung geschiitzt ist 65 

10. Verfahren nach Anspruch 9, gekennzeichnet dadurch, daB als biometrisches Merkmal eines oder mehrere der 
Folgenden verwendet werden konnen: 

individueller Fingerabdruck 



21 



c 



DE 101 21 819 A 1 



individuelle Iris-Musterung 
individuelle Gesichtsziige 
individuelle Sprache 
genetische Muster 

Muster aus der Gen-Exprimierung, insbesondere RSA und Proteine 

11. Verfahren nach Anspruch 1 bis 10, gekennzeichnet dadurch, daB fur die Identifikation des Authentifizierungs- 
kontextes eine eindeutige binare Sequenz als "Session Key" verwendet wird 

12. Verfahren nach Anspruch 11, gekennzeichnet dadurch, daB der Session Key mit privaten Schliisseln von am 
Kontext beteiligten Personen verschliisselt wird 

13. Verfahren nach Anspruch 3, 11 und 121 gekennzeichnet dadurch, daB die Integritat des Authentifizierungsan- 
trages dadurch gewahrleistet wird, daB der gesamte Antrag oder Teile davon mit dem Session Key oder einer davon 
abgeleiteten binaren Sequenz digital signiert wird 

14. Verfahren nach alien bisher genannten Anspriichen, gekennzeichnet dadurch, daB das System, das zur Anfor- 
derung der Datenfreigabe verwendet wird, Bestandteil des Authentifizierungskontextes ist 

15. Verfahren nach Anspruch 14, gekennzeichnet dadurch, daB 

das anfordemde System gegeniiber dem priifenden System durch ein unabhangiges asymmetrisches Schlusselpaar 
identifiziert werden kann 

die Kommunikation zwischen anforderndem System und prufendem System verschliisselt erfolgen kann 

16. Verfahren nach Anspruch 15, gekennzeichnet dadurch, daB die Kommunikation zwischen anforderndem Sy- 
stem und prufendem System iiber eine Variante des Protokolls ssl oder tls ("secure Socket Layer") erfolgen kann 

17. Verfahren nach Anspruch 16, gekennzeichnet dadurch, daB zur Authentifizierung des Cerates gegeniiber der 
priifenden S telle und zur Verschlusselung der Dateniibertragung das Protokoll https ("http over ssl") verwendet wird 

18. Verfahren nach den bisher genannten Anspriichen, gekennzeichnet dadurch, daB die Oberpriifung der Giiltig- 
keit von Authentizitatsbehauptungen anhand einer dieser Moglichkeiten erfolgt: 

eines bei der priifenden S telle hinterlegten offentlichen Schlussels als Gegenstiick zum privaten Schlussel des zu au- 
thentifizierenden Akteurs 

der elektronischen Bescheinigung einer vertrauenswiirdigen Instanz ("Trust Center"), deren offentlicher Schlussel 
bei der priifenden Stelle vorliegt 

der elektronischen Bescheinigung einer vertrauenswiirdigen Instanz ("Trust Center"), deren Authentizitat von einer 
Kette aus Authentizitatsbescheinigungen besteht, wobei am Anfang der Kette eine Instanz stent, deren offentlicher 
Schlussel bei der priifenden Stelle vorliegt 

19. Verfahren nach Anspruch 18, gekennzeichnet dadurch daB fur-Authentizitatspriifung die Verfahren verwendet 
werden, wie sie in ISO X.509 festgelegt sind 

20. Verfahren nach Anspruch 18 und 19, gekennzeichnet dadurch, daB zur Authentiflkation erforderliche Zusatzin- 
formationen (z. B. X.509-Zertifikate, Zerdfikatsketten oder vergleichbare Daten) zusammen mit dem Freigabean- 
trag uberrnittelt werden konnen 

21. Verfahren nach Anspruch 18, 19 und 20, gekennzeichnet dadurch, daB die zur Authentizitatspriifung erforder- 
lichen offentlichen Schlussel sich in einer Datenbank an einer der folgenden Standorte befinden: 

der priifenden Stelle selbst 

innerhalb der unmitteibaren, kontrollierbaren Sicherheitssphare der priifenden Stelle 

einer offentlich verfugbaren Stelle, zu der von der priifenden Stelle aus eine unverfalschbare Daten verbindung be- 
steht 

22. Verfahren nach Anspruch 21, gekennzeichnet dadurch, daB die tJbertragung zwischen der priifenden Stelle und 
der Datenbank durch eines der folgenden standardisierten Protokolle erfolgt 

ITU-T- Empfehlung X500 ff. 

Lightwighted Directory Access Protocol (LDAP) 

23. Verfahren nach einem der bisher genannten Anspriichen, gekennzeichnet dadurch, daB 

die Priifung der Authentizitat der Freigabe erteilenden Akteure durch eine andere Stelle erfolgen kann als der, die 
die Daten frei gibt 

die Freigabe der Daten durch eine andere Stelle erfolgen kann als der, die die Daten gespeichert hat 

24. Verfahren nach 23, gekennzeichnet dadurch, daB 

die priifende Stelle an die freigebende Stelle einen geeigneten Datensatz iibertragt, der der freigebenden Stelle die 
Evaluation des Kontextes ermoglicht ("push Session Request") 

dieser Datensatz an der freigebenden Stelle gespeichert werden kann, bis eine Anforderung von der abrufenden 
Stelle erfolgt 

und/oder aufgrund des Freigabedatensatzes bereits Daten an die abrufende Stelle gesandt werden konnen 

25. Verfahren nach 23, gekennzeichnet dadurch, daB die freigebende Stelle von der priifenden Stelle einen geeig- 
neten Datensatz abruft, der der freigebenden Stelle die Evaluation des Kontextes ermoglicht, sobald eine Anforde- 
rung zur Datenfreigabe an sie gerichtet wird ("pull Session Request") 

26. Verfahren nach Anspruch 23 bis 25, gekennzeichnet dadurch, daB 

die Kommunikation zwischen freigebender und priifender Stelle mit wechselseitiger kryptographischer Authentifi- 
zierung erfolgen kann 

die Kommunikation zwischen freigebender und datenhaltender Stelle mit wechselseitiger kryptographischer Au- 
thentifizierung erfolgen kann 

die Kommunikation zwischen freigebender und priifender Stelle verschliisselt erfolgen kann 
die Kommunikation zwischen freigebender und datenhaltender Stelle verschliisselt erfolgen kann 

27. Verfahren nach Anspruch 26, gekennzeichnet dadurch, daB 

die Kommunikation der benannten Systeme iiber ssl (oder tls) erfolgt 
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die Kommunikation der benannten Systeme uber https erfolgen kann 

28. Verfahren nach Anspruch 23, gekennzeichnet dadurch, daB anstatt oder erganzend zu einer direkten Kommuni- 
kation zwischen freigebender und priifender SteUe die prufende Stelle ein geeignetes, von der.prufenden S telle si- 
gmertes, kryptographisches Datum ("ticket" oder "token") an die anfordernde Stelle iibermittelt, das die Richtigkeit 
der Authentifizierung beweist und mit dem sich dann die anfordernde Stelle der freigebenden Stelle gegeniiber aus- 5 
weisen kann 

29. Verfahren nach Anspruch 28, gekennzeichnet dadurch, daB dieses Token uber geeignete http-state-Manage- 
ment-Technologien ubertragen wird, insbesondere 

im Browser der anfordernden Stelle gespeicherte Variableninhalte ("Cookies") 

von Requestzyklus zu Requestzyklus weitergereichte URL-Query- bzw. HTTP-POST- Variablen-Inhalte 10 

30. Verfahren nach bisher genannten Anspruchen, gekennzeichnet dadurch, daB 

die freigebende Stelle uber eine "Zugriffskontroiliste" verfugt, die angibt, wer unter welchen Voraussetzungen Zu- 
griff mit welcher Berechtigung auf welche Daten hat 

der Inhalt des Zugriffsantrages, insbesondere auch die entsprechenden Informationen iiber den Zugriffskontext, mit 
den Vorgaben aus der Zugriffskontroiliste verglichen werden und daraus die zugestandenen Zugriffsrechte abgelei- 15 
tet werden 

31. Verfahren nach Anspruch 30, gekennzeichnet dadurch, daB die freigebende Stelle die Zugriffskontrollinfonna- 
tionen bei Bedarf von dem datenhaltenden System abruft 

32. Verfahren nach Anspruch 30, gekennzeichnet dadurch, daB die datenhaltende Stelle die Zugriffskontrollinfor- 
mationen direkt mit den erbetenen Daten - noch vor der Berechtigungspriifung - an die freigebende Stelle ubermit- 20 
telt 

33. Verfahren nach Anspruch 32, gekennzeichnet dadurch, daB 

das datenhaltende System die erbetene Antwort an das freigebende System im HTML-Format ubermittelt 

die Zugriffskontrollinformationen als spezifische, im Browser nicht storende oder vom Freigabesystem zu entfer- 

nende HTML-Tags ubermittelt werden 25 

34. Verfahren nach Anspruch 32, gekennzeichnet dadurch, daB 

das datenhaltende System die erbetene Antwort an das freigebende System im XML-Format ubermittelt 
die Zugriffskontrollinformationen als eigens dennierte XML-Elemente oder -Attribute ubermittelt 

35. Verfahren nach bisher genannten Anspruchen (insbesondere 14 bis 17), gekennzeichnet dadurch, daB 

der Zugriff auf freigegebene Daten nur von dem System aus erfolgen kann, das die Freigabeanforderung erstellt hat 30 
die Authentifizierungsinformationen des Zugriff veriangenden Systems vom Authentiztat prufenden System an das 
freigebende System mit ubermittelt werden 

diese Authentifizierungsinformationen netzwerkspezifische Daten (z. B. IP-Adresse, DNS-Namen) enthalten kon- 
nen 

diese Authentifizierungsinformationen Bestandteile oder eindeutige Merkmale eines kryptographischen Schlussel- 35 
paares enthalten konnen 

36. Verfahren nach Anspruch 35, gekennzeichnet dadurch daB 

die prufende Stelle an die freigebende Stelle den ssl-Ctient-Schlussei der anfordernden Stelle ubermitteln kann 
die freigebende Stelle mit der anfordernden Stelle iiber ssl oder tls (ggf. als https) kommunizieren kann 

37. Verfahren nach bisher genannten Anspruchen, gekennzeichnet dadurch, daB die Kommunikation zwischen der 40 
freigebenden Stelle mit der anfordernden Stelle auf Netzwerk- und/oder Datenebene mit (unter anderem) einem 
oder mehreren der folgenden Schlussel verschliisselt und/oder authentifiziert werden kann: 

Session-Key der kontextbezogenen Anforderung 

Schlusselpaar einer oder mehrerer der am Kontext der Anforderung beteiligten Personen 

Schlusselpaar des zur Anforderung verwendeten Systems 45 
Schlusselpaar des freigebenden Systems 

38. Verfahren nach Anspruch 37, gekennzeichnet dadurch, daB anstatt einer direkten Verschlusselung auch eines 
der in der Kryptographie bekannten Hybridverfahren verwandt werden kann 

39. Verfahren nach bisher genannten Anspruchen, gekennzeichnet dadurch, daB 

freigebende und datenhaltende Stelle in einer Firewall-Topologie eingebaut sind ^ 50 

hierbei die datenhaltende Stelle im geschutzten internen Bereich und die freigebende Stelle in der "DMZ" ("entmi- 
litarisierten Zone") der Firewall liegen kann 

40. Verfahren nach Anspruch 39, gekennzeichnet dadurch, daB die freigebende Stelle als "Application level Proxy" 
auf Schicht 7 des OSI-Referenzmodells realisiert ist 

41. Verfahren nach bisher genannten Anspruchen gekennzeichnet dadurch, daB 55 
die Freigabe der Daten in mehreren Anforderungszyklen erfolgen kann 

die Freigabe anfordernden Personen dabei weitere Kontextinformationen nachliefern konnen 

die Freigabe erteilende Stelle Informationen uber verfugbare Daten und/oder erforderliche weitere Kontextinforma- 
tionen an die Freigabe anfordernde Stelle senden kann 

durch wiederholte Zyklen der Umfang der freigegebenen Daten erweitert oder konkretisiert werden kann 60 

42. Verfahren nach Anspruch 41 gekennzeichnet dadurch, daB 

zur Vermittlung zwischen den Zyklen Hyperlinks, wie sie etwa aus dem WWW bekannt sind, verwendet werden 
konnen 

diese Hyperlinks statisch festgelegt oder dynamisch von den beteiligten Systemen generiert werden konnen 

43. Verfahren nach Anspruch 41 und 42, gekennzeichnet dadurch, daB die Hperlinks in Dokumenten folgender 65 
Struktur enthalten sein konnen: 

Hypertext Markup Language (HTML) 
Extended Markup Language (XML) 
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44. Verfahren nach Anspruch 41 bis 43, gekennzeichnet dadurch, daB zur "Obertragung wahrend der Anforderurigs- 
zyklen eine Variante des Internet-Protokolls http (insbesondere auch https) verwendet wird 

45. Verfahren nach bisher genannten Anspriichen, gekennzeichnet dadurch, daB 

an die S telle von naturlichen Personen auch andere juristische Persbnen treten konnen 
Personen auch andere vertreten konnen 

die Rolle von Personen, die im eigenen Namen oder in Vertretung handeln, von datentechnischen Systemen iiber- 
nommen werden kann, die inrierhalb des beschriebenen Verfahrens das gleiche Verhalten zeigen, und deren Funk- 
tion davon abhangig ist, daB die vom System vertretene Person diese Handlung durch eine WillensauBerung dem 
System gegeniiber kundgetan hat. 
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Zeichnung 2 - Beispiel der Authentifizierungsoberfiache (Entwicklungsinstallation): 
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ZEICHNUNGEN SEITE3 Nummer. DE10121819A1 

IntCI. 7 : G06F 12/14 . 

Offenlegungstag: 21. November 2002 

Zeichnung 3 - Zertifikatsverwaltung in einem Standard-Browser: 
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